.DEVICE XGP
.!XGPCOMMANDS←"/TMAR=100/PMAR=2220/BMAR=100"

.FONT 1 "BASL30.FNT[IJ,DBL]"
.FONT 2 "BASB30"
.FONT 3 "NGR25"
.FONT 4  "BASI30.FNT[IJ,DBL]"
.FONT 5  "NGR40"
.FONT 6  "FIX25"
.FONT 7  "NGR20"
.FONT 8  "GRFX35.FNT[NUM,AJC]"
.TURN ON "↓_π{"
.TURN ON "⊗" FOR "%"
.PAGE FRAME 50 HIGH 89 WIDE
.AREA TEXT LINES 1 TO 49
.AREA FOOTING LINE 50
.!XGPLFTMAR←120
.SPACING 70 MILLS
.PREFACE 180 MILLS
.NOFILL
.PAGE FRAME 50 HIGH 89 WIDE
.AREA TEXT LINES 1 TO 49
.AREA FOOTING LINE 50
.PREFACE 45 MILLS
.FILL
.COUNT PAGE PRINTING "1"
.NEXT PAGE
.PAGE←0
.MACRO B ⊂ BEGIN VERBATIM GROUP ⊃
.MACRO BB ⊂ BEGIN NOFILL SELECT 3 INDENT 0 GROUP ⊃
.MACRO E ⊂ APART END ⊃
.MACRO D ⊂ ONCE PREFACE 100 MILLS ⊃
.MACRO BBB ⊂ BEGIN  INDENT 0  PREFACE 100 MILLS  SPACING 45 MILLS ⊃
.TABBREAK
.NEXT PAGE
.PAGE←0
.BEGIN CENTER
.GROUP SKIP 3
⊗5  BEINGS:  KNOWLEDGE AS INTERACTING EXPERTS⊗*

.GROUP SKIP 3

⊗2Douglas B. Lenat
Stanford Artificial Intelligence Laboratory
Stanford, California⊗*

.GROUP SKIP 8

⊗5↓_ABSTRACT_↓⊗*

.END

.INDENT 6

	Knowledge may be organized  as  a
community  of  interacting  modules. Each module is granted
a complex structure, to simulate a particular expert in some small domain.
An extended analogy is drawn to a group of cooperating human specialists.
Based on this,
an internal constraint is imposed on the modules:
Their structure  must be  standard  over  the  entire
community.
Some advantages  of  a  uniform  formalism are thereby preserved.
An  experimental  community was
implemented  for  the task domain of automatic programming.
It has managed to synthesize 
a few inductive
inference  LISP  programs, nonformally,  from  specific  restricted
dialogues with a human user. 

.EVERY FOOTING(,⊗7{PAGE}⊗*,)
.TURN OFF "{}"
.PAGE←0
.NEXT PAGE

.BEGIN CENTER
⊗5  BEINGS:  KNOWLEDGE AS INTERACTING EXPERTS⊗*

⊗2Douglas B. Lenat
Stanford Artificial Intelligence Laboratory
Stanford, California⊗*
.END
.B

.E
.ONCE CENTER
⊗5↓_5. The parts of a BEING_↓⊗*

A set of 29 ubiquitous questions were chosen, representing everything one
expert might want to ask another. 
At least, they naturally encompass those questions which were asked during the
simulated meeting, hence should be sufficient for generating CF.
Q, this
universal set of BEING parts, is listed in the box below.
The percentage of the experimental pool  of BEINGs
which actually needed each part is also noted.

.BEGIN NOFILL GROUP
.PREFACE 0 MILLS
.INDENT 2 SELECT 3

⊗8⊂ααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααα⊃⊗*
⊗8~⊗*						⊗2↓_BEING Parts_↓⊗*
⊗8~⊗*
⊗8~⊗*⊗2WHAT⊗* 82%  A brief summary of the global purpose, a template for an English phrase.
⊗8~⊗*⊗2WHY⊗* 77%  A justification of the BEING's existence, partly filled in by the BEING who called it.
⊗8~⊗*⊗2HOW⊗* 72%  A summary of the methods the BEING intends to employ. Global strategies.
⊗8~⊗*⊗2IDEN⊗* 54%  How this BEING is referenced in English phrases. Implemented as productions.
⊗8~⊗*⊗2WHEN⊗* 19%  Why this BEING should be given control now. The sum of weighted factors.
⊗8~⊗*⊗2ARGS⊗* 63%  Number of arguments; which are optional; names of any local variables.
⊗8~⊗*⊗2ARG-CHECK⊗* 81%  Predicates which examine each argument for suitability.
⊗8~⊗*⊗2EVAL-ARGS⊗*  4%  Which arguments are to be evaluated, and which quoted.
⊗8~⊗*⊗2REQUISITES⊗* 10%  If this BEING is actually chosen, what must be made true prior to (pre)
⊗8~⊗*		during (co), and after (post) execution.  Work to make these true (unlike ARG-CHECK).
⊗8~⊗*⊗2DEMONS⊗* 7%  Set of demons to be kept active while the BEING is in control.
⊗8~⊗*⊗2INHIBIT-DEMONS⊗*  5%  A lock/unlock mechanism, useful when handling demonic interrupts.
⊗8~⊗*⊗2EFFECTS⊗* 27%  What will probably be true after this BEING is through. What it achieves.
⊗8~⊗*⊗2RESULTS⊗* 15%  How many values this returns. What domain each is in. Side effects.
⊗8~⊗*⊗2META-CODE⊗* 70%  The body of the executable code, but with uninstantiated subparts.
⊗8~⊗*⊗2COMMENTS⊗* 16%  Hints for filling in undefined sections of other BEING parts.
⊗8~⊗*
⊗8~⊗*⊗2STRUCTURE⊗* 4% Viewing this BEING as a data structure, the operations doable to it.
⊗8~⊗*⊗2AFFECTS⊗* 14%  Other BEINGs which might be called by this BEING, and why.
⊗8~⊗*⊗2COMPLEXITY⊗* 92%  A vector of utility measures, including probable ease of calling,
⊗8~⊗*		success, (calling)* itself, time/space cost, efficiency of its output resul8ts.
⊗8~⊗*⊗2GENERALIZATIONS⊗* 27%  Some other BEINGs, encompassing this one.
⊗8~⊗*⊗2ALTERNATIVES⊗* 16%  Some equivalent BEINGs (to try if this one fails).
⊗8~⊗*⊗2SPECIALIZATIONS⊗* 40%  How to write a streamlined, special-case version of this BEING.
⊗8~⊗*⊗2ENCODABLE⊗* 9%  How to order the evaluation of the other parts for self-streamlining.
⊗8%ααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααα$⊗*
.END

Each of the 100 BEINGs in PUP6 should have
had a value for each part (in reality, only 40% were filled in; only 30% were
actually necessary to generate CF). A value for a part is simply a LISP
program which can answer that question, often by asking questions of the
same BEING, of other BEINGs, and of the user. A part may also assert some fact,
create or modify some structure (including demons, BEINGs, and parts of BEINGs).
Appendix 1 shows the values stored under each part
for a typical BEING. 
The reader is invited to glance over this table now.

The set of parts breaks into three rough categories: those parts which
are useful in deciding which BEING gets control, those useful only to
answer the user's questions and keep him oriented, and those used once
the BEING gains control.  Each of these three groups of parts will be
described.

.ONCE INDENT 0
⊗2↓_5.1. When a BEING Gains Control_↓⊗*

At the humans' meeting, only one expert spoke at a time; in the BEINGs
community, only one BEING has control at any given moment. He uses his
parts to do things (ask, create, modify), and yields control either
voluntarily or through interruption. 

In slightly more procedural terms, the scenario is as follows. One part of
a BEING senses its relevance (often the IDEN or EFFECTS parts, which are
united with all such parts to form a large production system). If more than
one BEING wants control at any time, a special BEING, CHOOSER, seizes
control momentarily. He asks each competing 
BEING to evaluate its WHEN part, to see
how seriously it needs to go immediately. If some BEINGs are still tied for
first place, he asks them to evaluate their COMPLEXITY parts, to see which is
the simplest. If any ⊗4still⊗* tie for top, one is randomly chosen. In any
case,the winner is then passed control. Once in control, a BEING arranges
some of its parts in some order and evaluates them. For example, the ARGS
part might be first; if it asks for some arguments which no BEING has 
supplied, then the whole BEING might decide to fail. Some  parts, when evaluated,
might create a new BEING, might ask questions which require this whole process
to repeat recursively, etc. 
This "asking" really means broadcasting a request to one or two parts of
every BEING; for example "Is there a known fast way of gronking toves?" would
be asked as a search for a BEING whose COMPLEXITY indicated speed, and whose
EFFECTS part contained a production with a template matching "gronking toves".
A list of the responders would be returned. 
(Incidentally, GERUND would recognize this, but later give up when no one
could recognize "gronk toves".)
The questioner might pose some
new questions directly to these BEINGs, might turn control over to them directly,
etc. One way or another,
the BEING eventually relinquishes control. If it had no direct successor in mind,
all the BEINGs are asked if they want to take over.  
There will always be ⊗4some⊗* BEING who will take over;
the general management
types of BEINGs are always able  -- but reluctant  -- to do so. 

How does each BEING decide which parts to evaluate, and in which order,
once it gains control?
The answer might seem to be difficult or tedious for whoever writes
BEINGs, since it might vary from BEING to BEING. In fact,
it doesn't!
The commitment to a universal set of BEING parts is inefficient in some ways
(each BEING ⊗4needed⊗* only a third of all the parts) but allows for some
simplifications right here. 
What parts should be evaluated, and in what order, when a 
BEING gains control? This decision depends primarily on the ⊗4types⊗* of parts
present in the BEING, not on their ⊗4values⊗*.  But every BEING has the same
anatomy, so one single algorithm can assemble any BEING's parts into an executable
LISP function. Moreover, this assemby can be done when the system is first
loaded (or when a new BEING is first created), and need only be redone for a
BEING when the values of its parts change. Such changes are rare: experts are
not often open-minded. 
The precise algorithm is sketched in the box below. The parts useful here include
ARGS, DEMONS, META-CODE, COMMENTS, ARG-CHECK, and REQUISITES.

.BEGIN GROUP
.SPACING 20 MILLS PREFACE 60 MILLS
.SELECT 3  
⊗8⊂αααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααα⊃⊗*
.BEGIN NARROW 2,2 
.ONCE CENTER
⊗2↓_Algorithm for assembling a BEING into an executable function_↓⊗*

When a BEING ⊗4B⊗* first gains control, its ⊗3EXPLICIT-ARGS⊗* are bound. The
⊗3IMPLICIT-ARGS⊗* are initialized, the name ⊗4B⊗* is pushed onto the BEING
control stack, and any newly-activated ⊗3DEMONS⊗* are so tagged. The
BEING who called ⊗4B⊗* should have explained his reasons by assigning
some phrase to the variable ⊗3BECAUSE⊗*.  This reason is now stored as a
special sub-part of the ⊗3WHY⊗* part of ⊗4B⊗*.
⊗3BECAUSE⊗* is rebound periodically in the ⊗3META-CODE⊗* and ⊗3COMMENTS⊗* parts, to
keep current the explanation of each call that ⊗4B⊗* makes. 
Each ⊗3ARG-CHECK⊗* predicate is evaluated. If any returns NIL, the
entire BEING reports that it has failed; otherwise, the
⊗3PRE-REQUISITES⊗* are examined. Effort is expended to make them true, if they
are currently not satisfied. Each ⊗3COMMENT⊗* is evaluated, then the
⊗3CO-REQUISITES, META-CODE⊗*, and the current demons
are executed in pseudo-parallel.  Each ⊗3POST-REQUISITE⊗* is then examined, and
an effort made to satisfy it.  The newly-activated demons are exorcized,
⊗4B⊗* is popped from the BEING control stack,
and the value computed by the ⊗3META-CODE⊗* is returned.

Some heuristics were devised to take advantage of the fact that the BEINGs often
didn't need many of the standard parts. For example, ⊗3INFO-OBTAINER⊗*
has no new demons or co-requisites, so no parallel processing need be simulated.
No results are explicitly produced, so the value returned by the ⊗3META-CODE⊗* is
not saved and later returned.
Here is the way that BEING actually appeared after assembly;
contrast this with the values of
its parts, as presented in Appendix 1.
Notice that BECAUSE is set to the reason that CHOOSE-FROM is called.
.NOFILL INDENT 4 
.PREFACE 25 MILLS

(INFO-OBTAINER
   (LAMBDA  (U)
        (AND
           (PUSH  INFO-OBTAINER  BEING-STACK)
           (PUT-APPEND  INFO-OBTAINER  WHY  BECAUSE)
	   (EVERY  CURRENT-DEMONS  APPLY*)
	   (SETQQ BECAUSE (WE CAN ONLY TRY TO OBTAIN USABLE INFO IN ONE WAY AT A TIME))
	   (CHOOSE-FROM   
		     (GET-NEW-INFORMATION U)
		     (TRANSLATE U)
		     (ANALYZE-IMPLICATIONS U)
		     (EXTRACT-RELEVANT-SUBSET U))
           (POP   BEING-STACK))))
.FILL
.END
⊗8%αααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααααα$⊗*
.END

.ONCE INDENT 0
⊗2↓_5.2. Keeping the User Informed_↓⊗*

In the earlier conversation excerpts, the simulated human user had no trouble
whatever understanding what the simulated experts asked him. In the actual
programmed PUP6 system, the human who was sitting at the teletype quite
⊗4rarely⊗* understood what was wanted by the BEINGs. He frequently had to
interrupt them and ask them questions about who was in control, why, what
he was trying to do, what had recently transpired, etc. These ideally can
be phrased as simple retrievals and EVALs of active BEINGs' parts.
The BEING parts
most often called for by the user are the simple one-line "orientation"
templates. These include WHAT, HOW, WHY, and AFFECTS.  For 
theoretical reasons explained
later, the synthesized program, CF, was writen as a pool of BEINGs itself
(by PUP6, but not during the protocol. Actually, a fortuitous 
"bug" in PUP6 created this intriguing situation.)
Although its question-answering ability is inferior to PUP6, the fact that it
has ⊗4any⊗* such power was surprising to the author. In other words,
one can interrupt the target program as it is running
and ask questions. Any BEING on the control stack will provide fully instantiated
answers to any of its 29 allowable queries (its parts); all other BEINGs will provide only
hypothetical answers. As an example, consider this actual excerpt of a human
using the CF program synthesized by PUP6.
(Some liberty has been taken with the
English; e.g., the user really types ⊗4WHAT?⊗*, not ⊗4What are you doing?⊗*)
"???" simply means "guess the name of the scene with these objects and relations".
CF types in boldface, the user in italics.

.SKIP TO COLUMN 1
.BEGIN NOFILL FLUSH LEFT SELECT 2
READY TO ACCEPT BRAND NEW SCENE:   ⊗4(??? (A B) (Block A) (Green B) (Touches A B))⊗*
NOT AN ARCH. NOT A TOWER. MIGHT BE A ROW.  MY GUESS IS ROW.
WHAT IS IT REALLY?		   ⊗4Nothing⊗*
TRANSFER FROM MAY TO MUST SETS OF ROW: (TOUCH A B)
READY TO ACCEPT BRAND NEW SCENE:
.END

Here is the ⊗4same⊗* excerpt, but with the user interrupting occasionally.
"⊗4U:⊗*"
signifies he has interrupted,
and "⊗4OK.⊗*" signifies he has told CF "⊗4OK, go back to work now.⊗*"

.BEGIN NOFILL FLUSH LEFT SELECT 2

	⊗4U:  What are you doing?⊗*
CF:  Divide a domain into subdomains, using specialized version of PARTITION-DOMAIN.
  	⊗4How?⊗*
CF:  By building up the partition gradually, by adding one <scene, name> pair.    ⊗4OK.⊗*
.D
READY TO ACCEPT BRAND NEW SCENE:   ⊗4(??? (A B) (Block A) (Green B) (Touches A B))⊗*
.D
	⊗4U:  What are you doing?⊗*
CF:  Break OBJECTS piece off (??? (A B) (BLOCK A) (GREEN B) (TOUCHES A B)) to examine.
	⊗4What code is the current BEING going to execute?⊗*
CF:  The meta-code of SOME-PART-OF↓1↓4 is (CADR arg1). Evals to (A B).    ⊗4OK.⊗*
.D
NOT AN ARCH.
	⊗4U:  Why?⊗*
CF: The ARCH MUST-relation (SUPPORTS A B) is contradicted in the SCENE.    ⊗4OK.⊗*
.D
NOT A TOWER. MIGHT BE A ROW.  MY GUESS IS ROW.
WHAT IS IT REALLY?		   ⊗4U:  Why are you asking?⊗*
CF: CF cannot resolve it, and must at this time, so CF asks USER
	⊗4OK. What you wanted is:   Nothing⊗*
.D
	⊗4U:  What are you doing?⊗*
CF: Go through space of concept names, and make user aware of changes.
	⊗4What BEINGs might this affect?⊗*
CF: MESSAGE is possibly called; some version of TEST is possibly called.     ⊗4OK.⊗*
.D
TRANSFER FROM MAY TO MUST SETS OF ROW: (TOUCH A B)
	⊗4U:  Why?⊗*
CF: Change model of ROW until it contradicts the previous SCENE.	   ⊗4OK.⊗*
.D
READY TO ACCEPT BRAND NEW SCENE:

.END


.ONCE INDENT 0
⊗2↓_5.3. Passing Control in the System_↓⊗*


Rather than delve into detailed discussions about each BEING part which is
useful in passing control, another conversation example will be presented,
annotated as to why each BEING was able to gain control just when it did.
The BEINGs in PUP6 have the same
names, and carry on the same kind of discussion, as our earlier experts do.
Below, they work together to create the idea of structuring CF's internal models'
features into three disjoint sets: MUSTNOT, MUST, and MAY.  After each speaker's
name is, in brackets, a brief sketch of the parts involved in this
particular interaction. These parts are typically IDEN, WHEN, COMPLEXITY,
EFFECTS, and DEMONS. It is advised that the excerpt be read twice: once,
ignoring the information in the brackets, [...], to understand
⊗4what the BEINGs are saying⊗* (how the MUST/MUSTNOT/MAY idea evolves),
and once to attain a feel for how the control-passing parts work.

Assume the "meeting" of BEINGs has progressed to the stage where they know that CF
must compare the inputted scene against internally stored models of named scenes.
When a model is found which passes that comparison, its name is reported as CF's
guess for the scene. A predicate, a test, is desired. The experts ask each other
and the user ⊗4How do we know when a model has passed or failed the test?⊗*

.BBB

INFO-OBTAINER: [⊗6Final course of action in META-CODE part.⊗*] I
am going to consult the user on this matter. Someone take this message, please.

MESSENGER: [⊗6IDEN part recognizes relevance; META-CODE part types on 
teletype.⊗*]  User, how do we know whether the model we're examining is suitable?

USER: Fail if any feature of the model is in contradiction to the
features of the scene.

LOOP: 
[⊗6The IDEN part template "←act if any ←x ε ←X satisfies P(x)"
matches the last sentence. "act" is bound to "fail", "x" to "feature", etc.⊗*]
The outer structure called for is a loop through the model's features,
terminated when some test fails.

CONTRADICTION: 
[⊗6The IDEN part can handle "←x is in contradiction to the set ←Y"⊗*.]
This failure should occur
precisely when the model demands some property of a scene feature which that feature
doesn't possess. 

SCENE: 
[⊗6The IDEN part prods the STRUCTURE part, which already
understands what a scene is composed of, in particular what constraints are
imposed on the features.⊗*]
The only properties the scene's features can possess are that of absence and
presence. The user has already ruled out negation and combination of features.

TRANSLATE: 
[⊗6EFFECTS include uniting two related sentences, using substitution.⊗*]
Thus the predicate should return failure if the model specifies that a
feature be present and it is actually absent, or if the model specifies a feature
be absent when it is actually present in the scene.

PGMMER: [⊗6WHEN part has a very high rating now.⊗*]
I believe that, with LOOP's help, we understand this enough to program it.

CODER: 
[⊗6EFFECTS indicate this is the only BEING who should be active now.⊗*]
Give me the arguments and the body of the code.

LOOP: 
[⊗6DEMON recently set up just for this occasion is triggered.
SPECIALIZATIONS part now produces streamlined version of LOOP BEING itself.⊗*]
The arguments are two pointers: to the features of a model and to the
features of a scene.
The outer structure is to step through the model features until the test
returns failure. If this never happens, then report success.

PGMMER: 
[⊗6DEMON triggered here also. COMMENTS part contributes knowledge of
how to handle cases at this level.⊗*]
The testing function must check each model feature. If it is one which
must be present in the observed scene, then check for that presence. If it is one
which must be absent, check that it is in fact absent.

CODER: 
[⊗6Summoned by its EFFECTS part. META-CODE part suggests using COND for cases.
COMMENTS part warns that this only works if case tests are disjoint.⊗*]
I want to embed the tests in a COND. Can a model feature demand itself be
both present and absent from a scene?

SCENE: 
[⊗6IDEN grabs this. STRUCTURE part indicates that they are disjoint.⊗*]
No.

CODER: (scribbling)
.BEGIN NOFILL GROUP SELECT 3 INDENT 0
 (LAMBDA   (M-FEATURES  S-FEATURES)
   (FOR-EVERY  M-FEATURE  IN  M-FEATURES  
     (COND
       ((IS-OF-TYPE  M-FEATURE  MUST-BE-PRESENT)   (MEMBER  M-FEATURE  S-FEATURES))
       ((IS-OF-TYPE  M-FEATURE  MUST-BE-ABSENT)    (NOT (MEMBER  M-FEATURE  S-FEATURES)))
       (T     ...))))
.END
What happens if the model feature doesn't have to be present ⊗4or⊗* absent 
in the scene?

.INDENT 2

CONTRADICTION: 
[⊗6IDEN part recognizes relevance, WHAT part easily answers the question.⊗*]
Then there can be no contradiction. (Blank stare from CODER.)

PGMMER: 
[⊗6IDEN part is not anxious, but CODER's is even lower-valued. Examines the
CODE part of the TRANSLATE BEING.⊗*]
He means, the test function should return T.

.INDENT 0

CODER: 
[⊗6Regains control hierarchically. A REQUISITE must now be satisfied.⊗*]
Got it...  
This is still very tentative; does anyone see any undesired properties
of this piece of code?

CASE-SPLIT: 
[⊗6IDEN part responds, WHEN part is high enough to take control.⊗*]
That call on IS-OF-TYPE is too general, would take too much time. I
know a great deal about case testing. Explain to me what exactly is needed, and I
will replace each IS-OF-TYPE call by a much more efficient one.

.NEXT PAGE
.ONCE INDENT 2
GENL-MANAGER:
[⊗6IDEN reluctant; must fall back on very general management techniques.⊗*]
No one seems to understand you. Go through your bag of "tricks" one by
one, in detail.

CASE-SPLIT: 
[⊗6WHAT and HOW parts are presented to the pool; hoping for recognition.⊗*]
Many of the 
tricks deal with changing the internal representation of sets, to
make searches on them more efficient. Is their any constraint on how the features of
a model be stored?
(pause) Well, the biggest savings would result from replacing IS-OF-TYPE by the
fast function MEMBER. The next biggest gain would be to store all the "must be 
present" features before all the...

STRUCTURE-INDUCER: 
[⊗6IDEN indicates very high relevance. META-CODE is able to handle one of the
"tricks" all by itself.⊗*]
Wait. I don't see anything wrong with your first idea.
The model's features will be divided into 4 disjoint sets: those which must be
present, those which must be absent, those in both, and those in neither class.

SCENE: 
[⊗6DEMON part says that an inefficiency was just overlooked; COMPLEXITY
says it is urgent.⊗*]
There can be no features which must be both present and absent.

STRUCTURE-INDUCER: 
[⊗6Continues on⊗*]
So CF maintains 3 differently-named sets of features
for each model.

PGM-MANAGER: 
[⊗6COMPLEXITY has just risen past danger level.⊗*]
This seems like too big a step to go unreported to the user.

MESSENGER: 
[⊗6EFFECTS indicate this is the only BEING to call on now.⊗*]
I will tell him what was done. If he asks any questions, I'll relay
them back to you.

PGM-MANAGER: 
[⊗6REQUISITE part warns that this must be done soon.⊗*]
We must have proper names for the three types of sets.

NAMER: 
[⊗6EFFECTS part shows this is the ideal BEING to take over now. CODE does the
simple initials/mainwords/concat operations to produce mnemonic labels.⊗*]
How about "PRESENT, ABSENT, EITHER"?

USER: No. Call them "MUST-BE-PRESENT, MUSTNOT-BE-PRESENT, MAY-BE-PRESENT".

NAMER: [⊗6Length DEMON awakens⊗*.] 
Too long. We shall call them just "MUST, MUSTNOT, MAY".

WARNER: 
[⊗6WHEN sees relevance, META-CODE says to locate areas which will
possibly need revision.⊗*]
All previous accesses to models' features have been located and tagged.
Now what?

STRUCTURE-INDUCER:
[⊗6Specialized facts about the effect of substitutions on earlier code.⊗*]
Each such access must either be replaced by APPEND of three accesses, to
the three new names for sets of model features, 
or else the statement it is in must be replaced
by three similar statements.

ANALYST: 
[⊗6DEMON part wakes up at this blunder.⊗*]
Not always: not all three types of features may need
to be accessed each time.
.END

Considering the thousands of inter-expert transfers which preceded completion of
CF, it is not surprising that all these brief excerpts seem somewhat defocussed.
This price is tolerable since the BEING execution times are small, and since
the uniform structuring (which causes this lack of direction) benefits more than
it hurts (the system actually ⊗4works⊗*).

.B

.E
.ONCE CENTER